fix: resolve CSS-wide keywords and the inherited colour as CSS defines them - #391

The compiler and the resolver each asked whether a var() reads the
inherited colour, under one name with two meanings. The shallow question
is now `isInheritedColorLookup` beside the variable it names, and the
compiler's walk calls it for each var() it meets. Each constraint is stated
in one line, citing the sections that state it.

No caller passes parseUnparsed a string or a number: with either removed from the parameter
type, tsc reports no call site, and the test suite never takes either branch. The string
branch's `currentcolor` arm was a third spelling of the inherited-colour lookup that nothing
reached.

Each expected value is what Chromium, Firefox and WebKit compute for the same CSS. The cases
that pinned a divergence are gone: a light-dark() descendant in dark mode, a custom property
holding `inherit` that is not inlined, and the string relative colour syntax resolves to.
`::selection` is left to the pseudo-element mapping, and `::placeholder` also reads the
element's own colour.

A CSS-wide keyword is a value only on its own (css-values-4 §2.1), so the compiler resolves
one where it is a declaration's whole value or a var() fallback's, and rejects one inside a
longer value. `revert` and `revert-layer` roll back to `unset`, as React Native has no
user-agent or user origin. `unset` is `inherit` on `color` and on a custom property and
`initial` elsewhere, and `initial` clears the property to React Native's default. A custom
property left to inherit publishes nothing, so a read finds its ancestor's value, and its
warnings now name it.

A shorthand cleared by a keyword resets every longhand it sets, and a cleared filter is none.

An element's inherited colour comes from its last rule that publishes one, so a later `color`
that inherits no longer leaves an earlier rule's colour for its subtree, and a pseudo-element's
colour stays its own.

The first pass prints the stylesheet before the second parses it, so no white space from a
comment reaches the keyword, and the filter for it was unreachable.

A shorthand parsed at runtime was registered with an empty argument when its value failed to
parse, which cleared an earlier rule's value; browsers ignore an invalid declaration, so it is
left out. The CSS-wide keyword cases join the existing keyword suite.

… none

A filter or transform list that a var() fills with `none`, a cleared value or `initial` is
`none` alone or invalid at computed-value time, and either way the property is `none`; the
resolvers returned the keyword inside the list.

…rive cleared

Only a shorthand that returns its longhands as an object receives a cleared argument: animation
wraps its argument in a list, and box-shadow and drop-shadow handle it before the handler.

…he declaration

A keyword is a value only on its own, so one inside a function, a colour or a list makes the
whole declaration invalid; rejecting the token alone left `box-shadow: 1px 1px inherit` as a
shadow and `blur(inherit)` as an empty blur. A var() or env() defers its value, and a custom
property's value is any tokens, so neither is checked.

…CSS-wide keyword whole

These three parse their own value, so a keyword inside it was dropped as a token and the rest
applied: `object-position: left inherit` set `left`. They now share the declaration's keyword
decision, so the declaration is invalid and an earlier rule's value stands, as it does in
Chromium 153, Firefox 155 and WebKit 26.6.

… the function is

A fallback replaces its var() or env(), so a CSS-wide keyword in it applies only when the
function is the declaration's whole value (css-variables-1 §3). Inside a longer value the keyword
leaves the declaration invalid at computed-value time, yet it was resolved everywhere:
`color-mix(in srgb, var(--missing, inherit), blue)` mixed the inherited colour with blue, and
`translateX(var(--missing, initial))` compiled `unset` into the function. Inside a longer value
the fallback is now dropped with a warning.

An env() fallback is parsed for the declaring property, as a var() fallback is, rather than
under the env() name.

A keyword on its own was reported lowercased, while a nested one and every other value warning
quote the value as the stylesheet spells it.

…it sits

A var() with no fallback for a variable that has no value left its
declaration a value when it sat inside a list, a function or another
custom property: `--reader: var(--source) 1px` read `1px`, and a
custom property whose value failed fell back to its ancestor's
declaration instead of the reader's fallback. The lookup now records
the failed substitution itself, so the declaration is invalid at
computed-value time and a custom property holding one is the
guaranteed-invalid value (css-variables-1 §3.1). A channel rncss
publishes for a computed value, such as the em, is a default when
nothing publishes it, never a failure.

The inliner flattens every variable a value reads, inside functions
and fallbacks too, before substituting it, so the result no longer
depends on declaration order, and leaves each member of a cycle to the
runtime. A custom property reading the guaranteed-invalid value is
guaranteed-invalid itself, a declaration whose value substitutes to
nothing is unset, and an empty custom property keeps its empty value,
which substitutes nothing inside a list at runtime as well.

…me too

The compiler made a declaration whose value substitutes to nothing
unset, while the runtime handed React Native the empty list it left:
`margin: var(--a,) var(--b,)` with neither declared rendered
`margin: []` over an earlier rule's value. The list resolver records
when every entry substituted nothing, which leaves a property's value
invalid at computed-value time and a custom property's value empty, as
css-variables-1 §3.1 defines.

… left to the runtime

…ation that reads it

…ariables

…h the compiler resolves

…filter